Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9612/000061_owner-urn-ietf _Mon Dec 23 04:40:57 1996.msg

Internet Message Format | 1997-02-19 | 4KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id EAA27555 for urn-ietf-out; Mon, 23 Dec 1996 04:40:57 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id EAA27550 for <[e-mail]>; Mon, 23 Dec 1996 04:40:50 -0500
Received: from dicsmss1.jrc.it by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA04776  (mail destined for [e-mail]); Mon, 23 Dec 96 04:40:36 -0500
Received: from  jrc.it (elect6.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C)
    id AA25034; Mon, 23 Dec 96 10:45:34 +0100
Received: by  jrc.it (5.x/EB-950213-L)
    id AA17045; Mon, 23 Dec 1996 10:39:39 +0100
Date: Mon, 23 Dec 1996 10:39:39 +0100 (MET)
From: [e-mail]
X-Sender: [e-mail]
To: "Martin J. Duerst" <[e-mail]>
Cc: [e-mail], Ryan Moats <[e-mail]>,
        [e-mail]
Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt
In-Reply-To: <Pine.SUN.3.95.961221222804.245B-100000@enoshima>
Message-Id: <[e-mail]>
Reply-Path: [e-mail]
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
Reply-To: [e-mail]
Errors-To: [e-mail]


On Sat, 21 Dec 1996, Martin J. Duerst wrote:

> On Sat, 21 Dec 1996 [e-mail] wrote:
>
> > Ryan wrote:
> > > [e-mail] wrote:
> > > >
> > > >         3. suggested escape hatch for (grandfathered in) namespaces
> > > >            where the glyph representation is confirmed ambigious. (For
> > > >            example the $, #, pound and yen sign).
> > >
> > > This is already taken care of by the <excluded> character set.  The only
> > > way to put a character from this set in a URN is to use "%" encoding.
> > > Otherwise, the character terminates the URN.
> >
> > > It dawns on me that you may be talking about what hex value to use
> > > for the "%" encoding.  My current position is that it is the
> > > UNICODE/10646 value via UTF-8.
> >
> > No Actually not, What I meant is that I've seen people in the document
> > and library world using quite a few naming schemes where in different
> > places they use say the '$' and '$' with two lines through it and the '#'
> > and the L-shaped pound sign interchangably, depending on what keyboard
> > and machine they are working. So in these spaces the glyph-to-wire
> > encoding (using the % utf-8 encoding) is no longer trivial, as it is no
> > longer the shape of the symbol which matters.
>
> I start to understand. Real examples always make it easier.

Ok, here is a real example; P-R document references;

Country        They type (the keys/display on the screen)
France        #PEL/77124
UK        *PEL/77124  (Where the * is the oblique L
                 pound sign)
Greece        $PEL/77l24  (Note the 'l' instead of '1')
Holland        FlPEL/77l24 (Where fl is the florin symbol)

Luckily however the _wire_ format is perfectly sensible and
the same; But the fun bit is that they all happily print and
fax each other those references; and all know how to cope
with them just fine :-)

The point I am trying to make is that for some namespaces to
be grandfathered in have a stronger relation to their wire
octed stream than to the glyph/symbolic representation; so for
those you really want to ignore all you learned about really
neat UTF8 symbol encoding :-)

Dw.